New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: expose helpers for legacy versions of Node.js #1801
Conversation
helpers
Outdated
// TODO: remove this file once Node 10 is EOL: | ||
const { | ||
applyExtends, | ||
cjsPlatformShim, | ||
Parser, | ||
processArgv, | ||
} = require('./build/index.cjs'); | ||
|
||
module.exports = { | ||
applyExtends: (config, cwd, mergeExtends) => { | ||
return applyExtends(config, cwd, mergeExtends, cjsPlatformShim); | ||
}, | ||
hideBin: processArgv.hideBin, | ||
Parser, | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm confused, why an extensionless file instead of a helpers
dir with a package.json
that has "type": "commonjs"
and an index.js
file?
The current approach will be way more likely cause problems with parsers and resolvers (admittedly, ones with bugs, but i can't even confidently say resolve
would work properly with this)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate that having a subfolder would cleanup the top level a bit too, we could pull the mjs in there
@ljharb Deno was type issues, which should be fixed on the main branch already... I might have to move away from TypeScript for Deno unless someone wants to submit and maintain types that work. |
Expose helpers in extensionless
helpers
file, which older Node.js versions will interpret as a JavaScript file.This is the only approach I have found to circumvent exceptions thrown when loading
.js
files when type is set tomodule
.Fixes #1789